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ABSTRACT 

This paper describes the first-year results of 
Distributive Information Systems for Campuses (DISC), a project 
implemented in the Austin Independent School District (Texas). The 
goal was to increase the data access and information-generating 
capabilities of campuses by decentralizing data manipulation 
functions, while maintaining centralized data processing of major 
applications. A second project goal was to redesign student, school, 
and district profiles by consolidating reports Into a single, 
comprehensive report, creating a permanent, online data file. Major 
outcomes include: (1) design and creation of a new school profile; 
(2) resolution of a number of issues involving the creation of a 
large data file and printing a profile report; (3) implementation of 
an individual student profile; and (4) provision of some simple 
applications to schools* Additional progress needs to be made in the 
areas of providing campus staff training, increasing the hardware on 
campus, identifying software that campuses can use, and arranging for 
support personnel . Five figures are included. Attachments include 
sample profiles, specifications, and a file format for Megafile. 
(LMI) 
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ABSTRACT 



Distributive Information Systems for Campuses (DISC) is a project of the Department of Management 
Information (DMI) of the Austin Independent School District, Austin, Texas. The goal of the project is to 
increase the data access and information-generating capabilities of campuses by decentralizing data 
manipulation functions, while maintaining centralized data processing of major applications. To attain 
this goal, DISC is attempting to "distribute" access and analysis capabilities to campuses so that they may 
use more fully the extensive information available on the mainframe computer. Distributive information 
systems means that campuses could create desired reports more quickly, could customize them to meet 
their own needs, and would not need to rely so much on central processing facilities. In effect, DISC is 
about "moving data to the campuses." 

Moving data to the campuses means providing campuses with data resident on the mainframe computer in 
a form which they can manipulate. In the broadest sense, this effort will require the identification of 
appropriate training for staff, hardware, software, and support personnel. More immediately, simple 
applications to furnish to campuses can be identified — e.g., student/parent addresses for directories/ 
mailings and already-formatted data hies with software to query them. 

As a transitional stage to campuses creating their own custom reports, a second goal of DISC was to 
redesign student, school, and district profiles by consolidating a number of current reports into a single, 
comprehensive report and, in the process, creating a permanent, on-line data file which would be the basis 
for all future profiles. In the future, schools will be able to query downloaded portions of this file. 

An interdisciplinary team from DMI, including staff from the Office of Research and Evaluation (ORE), 
Data Services, and Data Processing/Interface, worked cooperatively to address the goals of the project. 
Other DM\ staff served in an advisory capacity to the team. Overall direction and allocation of priorities 
and resources were furnished by the Executive Director of DMI. 

Major findings are summarized below: 

1. In the first year of the DISC project, a new school profile was designed and produced. This 
profile consolidated information from, and replaced, several other profiles, including the 
District's annual performance report. The profile was provided to campuses in early March for 
campus planning and other purposes. 

2. In the process of producing the school profile, a considerable number of issues involved in 
creating a very large data file and printing a profile report were resolved. 

3. An individual student profile, which merges the concepts of local file access and electronic 
transfer of data, was implemented in fall 1992. 

4. Some simple applications — student/parent addresses for directories/mailings and already- 
formatted data files for campus data bases — were furnished to schools. 

5. Additional progress needs to be made in the areas of providing training for campus staff, increas- 
ing the hardware on campus, identifying software campuses can use, and arranging for support 
personnel. 
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INTRODUCTION 

Statement of the Problem 

Campuses need school-level information for many 
purposes — planning instruction, conducting 
inservice training, writing grant applications, and, 
especially, devising campus improvement plans 
(CIP's). Ideally, campuses should have access to 
and the means to manipulate data customarily 
collected and stored on a central computer. Typi- 
cally, however, large school districts produce and 
disseminate to campuses school "profiles" which 
are intended to report all of the information cam- 
puses need. The consequence of this central 
production of profiles is a double-bind situation. 
At the district level, considerable resources that 
could be directed toward other district priorities are 
tied up in creating profiles. Campuses, for their 
part, are dependent on central processing facilities 
which, no matter how comprehensive the effort, 
inevitably cannot produce all of the custom infor- 
mation they require when they need it. This paper 
discusses the first- year results of a project to shift 
away from centralized data production to school- 
based data self-sufficiency. 

Review of the Literature 

A profile, as defined by Broadfoot (1986) is a 
"method of displaying the results of an assessment; 
it is not a method of assessment. U is essentially 
derived from a separation of the whole of an 
assessment into its main parts or components." 
Profiles have been used in the field of education for 
a number of years. In public school education, 
interest in the use of profiles arose in part from a 
dissatisfaction with relying solely on test results as 
a description of a particular student's success in 
school. The profile format provided a way to 
describe a wider range of student, as well as 
campus and district, success, which included test 
results and other related and important elements 
that arc not overtly reflected in test scores, such as 
attendance rates, or enrollment in advanced 
courses. It was also thought that student, campus, 
and district profiles could provide practical feed- 
back to help motivate and guide principals, teach- 
ers, and students through the academic process. 



Profiles in education take many forms, but it is 
generally agreed by those in the field (sec Withers, 
1986) that, to be useful, profiles should: 

• Summarize performance, 

• Report academic as well as nonacadenuc 
outcomes, 

• Highlight more than one element or 
objective, 

• Contain important identifying information, 
such a* student name, school year, course 
names or numbers, etc. 

• Provide up-to-date information. 

Other features of useful profiles are: 

• Elements or objectives are not amenable to 
aggregation or averaging, and 

• Letters and numbers are reported with an 
explanatory key which gives meaning to 
codes, such as course numbers or letter 
grades, or other terms used. 

Withers (1986) offers the caveat that profiles 
should not intrude on the personal privacy of a 
student, or misrepresent, confuse, or fail to explain 
any assessment information. 

In sum, profiles provide a format for organizing 
large amounts of data into a concise, easy-to-read 
description which gives a comprehensive picture of 
the subject, whether an individual student, a school, 
or a school district. 

The widespread use of computers in education has 
aided the profile process by providing a means to 
compile and consolidate student and other relevant 
data more efficiently. This paper reports the first- 
year results from an intensive project to use 
computer technology to create comprehensive 
individual student, school, and district profiles and 
to look beyond profiles toward campus-based 
information systems. 

Perspective 

During the 1991-92 school year, staff of the 
Department of Management Information (DMI) of 
the Austin Independent School District (AISD), 
Austin, Texas, several times expressed a sentiment 
to the effect that "we want to get out of the profile 
business." The meaning of this remark is at the 
heart of the DISC project this report describes, a 
project which reflects in AISD the types of changes 
which have been occurring in major business 
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organizations throughout the 1980s. Getting out of 
the "profile business" means, most immediately, 
the central management information systems (MIS) 
department ceasing to produce statistical profiles of 
schools to send to campus personnel Profiles, 
though intended to convey useful and often re- 
quested information, amount in the aggregate to 
huge, expensive volumes of information, which are 
then sometimes infrequently used. In a larger 
sense, getting out of the profile business means 
shifting away from centralized data processing to 
distributive information systems, that is, moving 
from centrally located people using a large main- 
frame computer to produce information for person- 
nel at geographically dispersed sites to the users at 
those sites using their own computers to manipu- 
late available data bases and produce information 
they want. 

Background 

DISC, and the philosophy it embodies, did not 
spring up overnight. In 1991-92, a districtwide 
school-based improvement (SBI) initiative added 
impetus to a movement which had already been 
underway in the District for some time, that of 
automating certain processes ("applications" in 
data processing terms) to make them more effi- 
cient. For example, many personnel processes in 
AISD have been automated, some for many years 
(Wilkinson, 1990). To date, the automation of 
applications in AISD has occurred centrally on the 
mainframe computer, though District campuses 
have benefitted both directly and indirectly by the 
automation. In addition, campuses have in recent 
years been able to access a wide range of student 
and administrative data on the mainframe com- 
puter. On the whole, campuses have not, however, 
had the capability for manipulating these data to 
customize them for their local needs. Campus 
personnel have had to rely on the speed and 
availability of the central processing facilities to 
provide them with custom information. Consistent 
with a school-based management philosophy, the 
next step in the automation process was therefore 
evident. 

In data processing parlance, "distributive process- 
ing" refers to decentralized data processing, where 
data manipulation functions arc "distributed" to 
remote (i.e., nonccntral) locations. Distributive 
information systems implies that access to and 
analysis of data are decentralized. The aim of the 



DISC project is to "distribute" access and analysis 
capabilities to campuses, so that they may use more 
fully the extensive information available on the 
mainframe computer, while maintaining central- 
ized data processing of major applications. Dis- 
tributive information systems means that campuses 
could create desired reports more quickly, could 
customize them to meet their own needs, and 
would not need to rely so much on central process- 
ing facilities, including having to travel from their 
campuses to the central office to pick up computer 
output. 

Goals of the Project 

The two goals of the DISC project are: 

1. To redesign student, school, program, and 
districtwide profiles; and 

2. To increase data access and analysis 
capabilities at the campuses. 

"Profiles" refers here to a number of current reports 
which present data at various times of the year and 
with various definitions of the data being reported. 
In AISD, these include: 

• Academic Excellence Indicator System 
(AEIS) 

• Achievement Profile 

• Annual Performance Report (APR) 

• Effective Schools Standards Report 

• GENESYS (GENeric Evaluation SYStem) 

• Secondary Profile 

• School Characteristics and Ranks (SCAR) 

• Vital Signs 

A short description of each of these profiles is 
presented in Attachment 1. 

Such an array of reports pointed to the need to 
compare and contrast them and perhaps to merge 
them into a single, comprehensive report, while at 
the same time making provisions for new reporting 
requirements relating to Texas Education Agency 
(TEA) accreditation, Project A+ (a partnership 
project with IBM), and campus improvement plans 
(CIP's). In fact, this consolidation effort was one 
of the first activities undertaken by the DISC team 
(sec below), and it will be described fully later in 
this report. 
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Moving data to the campuses means providing 
campuses with data resident on the mainframe 
computer in a form which they can manipulate. 
In the broadest sense, this effort requires: 

• Identification of appropriate 
training for staff, 

• Hardware, 

• Software, and 

• Support personnel. 

More immediately, simple applications to furnish 
to campuses could be identified — e.g., student/ 
parent addresses for directories/mailings and 
already-formatted data files with software to query 
them. 

First- Year Objectives of the Project 

The first-year objectives of the DISC project 
were to: 

• Increase data access at the campuses, 

• Identify software campuses can use, 

• Redesign profiles, 

• Redesign applications: surveys, mailings, 
etc., and 

• Consider other issues: schools' use of 
AISD's data entry bid, CIP's, etc. 

The DISC project is not: 

• A data processing application effort such 
as grade reporting, payroll, attendance 
accounting, etc., 

• An SBI-dependent effort, 

• Mainframe operations, 

• Dependent upon additional budget 
requirements, 

• Reducing the central quality control of 
data, 

• Decentralizing data processing, or 

• "Dumping" work onto campuses. 

The DISC Team 

During the 1991-92 school year, an interdiscipli- 
nary team from the District's Department of 
Management Information (DMI), which includes 
both the Office of Research and Evaluation (ORE) 
and Data Services, worked cooperatively to address 
the goals and objectives of the project. The team 
members and the approximate percentages of their 
time allocated to the project arc shown below. 



These percentages take into account that the work 
of the team would accomplish much of the tradi- 
tional work of these positions — just in a somewhat 
different manner. 

Evaluator, 

Systcmwide Evaluation (team leader) 25% 
Evaluator, 

Systemwide Testing 15% 
Evaluation Associate, 

Systemwide Evaluation 25% 
Evaluation Associate, 

Systemwide Evaluation 75% 
Supervisor of Programming 15% 
Management Information Associate 15% 

The Chapter 1 evaluator and the two half-time 
Project A+ evaluation associates served in an 
advisory capacity to the team. Overall direction 
and allocation of priorities and resources were 
furnished by the executive director of DMI. 

Advisory Groups 

To help to focus on the needs of campuses, the 
DISC team sought advice and review of its work 
from a number of existing advisory bodies: 

• Data Processing Advisory Committee for 
Elementary, 

• Data Processing Advisory Committee for 
Secondary, 

• Advisory Principals' Team - Elementary 

• Quick Response Team - Secondary 

• Information Services Committee (ISC), 
and 

• Evaluation Advisory Committee (EAQ. 
REDESIGNING PROFILES 

School Profile 
Rationale 

Ironically, perhaps even paradoxically, the first 
step toward distributive information systems for 
campuses was the central production of a new and 
better school profile. Campuses' need for the 
information was evident in many requests, through 
many channels, for school-level information to 
fulfill many purposes — instructional planning, 
inscrvicc training, completing grant applications, 
and devising campus improvement plans. 



For example, in an administrative letter (August 
14, 1991) the Assistant Superintendent for Second- 
ary Education stated that "all CIP outcomes will be 
published in the Annual Performance Report,** a 
simpl . .atement belying the complicated produc- 
tion of a great deal of information! 

Against the reality of campus needs, however, was 
the recognition of the simple fact that the campuses 
do not yet have the technical capability or the 
training to create their own reports. This fact made 
it necessary to continue to produce a profile 
centrally, until such time that campuses could be 
given the means and be taught to produce their own 
profile information. 

The necessity of producing a profile centrally was, 
however, accompanied by the opportunity for 
bringing more coherence to the profile-making 
process. Over the years, ORE and DMI have 
created many different reports and reporting 
systems for conveying profile information to 
campuses and other audiences. See "Goals of the 
Project" above and also Attachment 1. Because 
much the same information is generally in demand, 
the content of these profiles overlapped and, 
because they reported data from various times of 
the year and with various definitions of the data 
being reported, the different profiles sometimes left 
users confused as to which number was the "offi- 
cial" statistic for the District. Although a system to 
document the "periodicity" of the data reported 
(Frazer, 1989) had evolved to describe the various 
reports of student information according to when 
they were produced and from what sources, it was 
time consuming to keep up and little understood 
outside DMI. One goal of the DISC project from 
the outset, therefore, was to redesign school and 
District profiles to consolidate all of the informa- 
tion being reported in different ways into a single, 
comprehensive report. 

Merely having a better profile was not the end 
result desired, however, because the goal of 
distributive information systems remained. More 
than just making a better mousetrap, DISC needed 
to make mousctaps obsolete — by creating an on- 
line file which would become the basis for future 
updates and queries. Thus was Mcgafile born— 
about which more will be said later. 

In summary, to the DISC team, producing profiles 
is clearly seen as a short-term, temporary expedi- 
ent, transitional to end users (campuses) being able 



to develop their own reports. This perspective 
crystallized in meetings of the DISC team in the 
fall of 1991. 

Designing the Profile 

On October 1, 1991, the DISC team and advisors 
met in a day-long meeting with the objective of 
having, by the end of the day, a handwritten draft 
of the format of the pages of the new Profile. The 
day-long meeting was itself an innovation, an 
experiment to determine if a group of people, used 
to functioning relatively autonomously could, if 
isolated from the usual distractions and interrup- 
tions and charged with a specific, time-governed 
goal, work cooperatively to achieve thai goal 
before returning to other activities. The "experi- 
ment" was a success. 

Success was ensured, in part, because several 
previous meetings in September had laid the 
groundwork for this new Profile. In fact, the whole 
concept of a profile was reexamined in terms of 
what information would be needed, by when, and 
how that information would be made available. 
Four options for making necessary information 
available were considered: 

Options: 

1. Separate profiles, each with 
a publication date 

2. Single profile with a single publication 
date when all data are available 

3. Single profile with cells completed as data 
become available — whenever profile is 
printed, available data are entered, other 
cells blank 

4. On-line profile (same as 2 or 3) 

Option 1 represented the status quo. The indi- 
vidual reports being produced would contain the 
profile information available at the time, and 
certain information would be available in the fall, 
other information in the spring. The drawback to 
this approach is that the "official" statistics for the 
District would never be in one place. Even with a 
system documenting the periodicity of the various 
reports (Frazer, 1989), confusion over which 
statistic to cite from which report would likely 
persist. 



Option 2 was the annual performance report (APR) 
option. Under State mandate, the District had been 
successfully producing APR's for several years, 
but a once-a-year report did not satisfy ongoing 
needs for the latest information, and by the time the 
report was published, it was in many ways an 
"historical" document, a record of the status of the 
District which was already out of date. 

Option 3 seemed a promising alternative to the 
problems with the first two options. "Official" 
numbers would be recorded when they were 
available, in a single place, and when printed, the 
profile would contain the most current data. In 
fact, DMI had such a system in place, SCAR (see 
Attachment 1), but it had been lately left untended, 
partly because it was structured around rankings, a 
concept from which the District was distancing 
itself. 

Option 4 was similar to the options 2 and 3, but it 
would feature an on-line file, available for viewing 
at any time. It seemed the most powerful and 
flexible option, but it would also be the most 
difficult to implement. 

In selecting among these options, team members 
found it useful to distinguish among levels of 
information (see below). Printing a profile, it was 
recognized, addressed only the first level of 
information. 

Levels of Information: 

• APR/on-line file 
(District/school information) 

• Class 

• Student 

Information at the class or student level, the team 
conceded, would need to be created by the indi- 
vidual campus. Thus, the inadequacy of profiles 
for the whole range of campus needs and the 
necessity to move to distributive information 
systems was reaffirmed. 

The medium through which the profile information 
would be promulgated was discussed. 



Possible Media: 

• Hard copy 

• On line interactive 

• CD 

• Diskette 

• Download on line (snapshot) 

• Hot line 

Although the other possibilities were intriguing, the 
team members decided that in view of the current 
technical capabilities of the campuses, and to have 
a permanent, historical record, a hard copy of the 
profile needed to be printed. The other formats are 
to be explored in the future. An on-line, interactive 
file is the next, logical outgrowth of the profile 
production process, but technical problems relating 
to the size of the file need to be worked out 

Once it was determined to go forward with a 
printed profile, while deferring an on-line profile, 
general guidelines for what the profile should 
contain were formulated. 

General Guidelines: 

• Disaggregate- ^extra lines/columns or 
separate pages for each subgroup. 

• Think of statistics not on any cuirent 
profile. 

• Give numbers and percentages. 

• Give a two-, three-, or five-year historical 
perspective. 

• Compare each campus to district totals. 

Features of the Profile were defined. 
Features: 

• Available on request 

• Most current data 

• Meaningful and useful to somebody (as 
many as possible) 

• Disaggregate by: 

School Chapter 1 Ethnicity 

Class LEP Grade Spans 

Individual Income Gifted/Talented 
Grade Sex 

• Positively stated — e.g., not retained 

• Glossary, index, table of contents, defini- 
tions, formulas, examples 

• Appropriate comparisons/valid rankings 



The team decided that not everything could be 
included in a single report. The level of detail and 
the mammoth size of the resulting report rendered 
that course infeasible. Some intact, stand-alone 
profiles would continue to be necessary, for 
example, the achievement profiles (Mangino, 
Rodgers, Wiser, & Meyer, 1991), which present 
achievement data disaggregated by school, by 
grade, by test area, and by ethnic group. 

The format in which the Profile would be printed 
was discussed, and a hierarchy by which tne 
reporting would be structured was formulated. 



Format (hierarchy): 

Area 

Indicator 

Subindicator 

Group 

Subgroup 

Statistic 



Example: 

Progress toward 
graduation 
Dropout rate 
Annual rate 
High school students 
Grade 9 

Number/percent 



Several other important format decisions were 
made: 

• Forget the number of pages, i.e., not be 
concerned with how long each school 
profile became or how voluminous the 
final product was. 

• Drop rankings, i.e., not rank campuses 
according to statistics such as 
dropout rate, etc. 

These decisions provided the foundation for the 
October 1 meeting, at which the format of the 
Profile was drafted. Each school's profile was 
divided into four major sections: 

1. School Description, 

2. Student Information, 

3. Staff Information, and 

4. Finance Information. 

Within each section, data would be arranged 
according to the hierarchy described above. The 
team decided that, wherever possible, all indicators 
should be disaggregated by ethnicity (Hispanic, 
Black, Other), sex, income, and grade level, and 
that as many years of data as possible would be 
printed. 



Some time was spent in discussion of the issue of 
comparison group statistics. The guiding principle 
the team developed was that the information 
presented in a school profile should be information 
for that school only, that comparison statistics 
should be expressed as a difference from the 
school — reflected through the school lens, as it 
were. Application of this principle means that 
comparative District, state, and national statistics 
would not be printed, only the school's differences 
from them. 

Outside Review 

In the process of designing the new Profile, the 
question of outside input arose. Essentially, the 
question was whether future users of the profile, 
most notably school principals, should be involved 
in helping to draft the profile. The executive 
director demurred from this line of thinking, 
arguing that the desires of users had long since 
been expressed, and that past experience had 
indicated that users found designing profiles more 
difficult than editing them. He also noted that DMI 
knew something about producing profiles since the 
previous year's APR had received national recogni- 
tion as best statistical profile from Division H of 
the American Educational Research Association 
(Ligon, Jackson, & Read, 1990). Hence, it was 
decided to proceed and to solicit review from 
knowledgeable, even critical, users once the Profile 
had been drafted. 

To this end, a group of principals was invited to 
attend a meeting on October 25, 1991, to review 
and react to a draft format for the Profile. Selected 
elementary, middle school, and high school princi- 
pals were invited. 

Subsequent review was provided by the: 

• Evaluation Advisory Committee 
(10/28/91), 

• Director of Special Technology Programs 
(11/12/91), 

• Information Services Committee (ISC) 
(11/15/91), 

• Assistant Superintendent for Elementary 
Education and the Director of Elementary 
School Services and Special Programs 
(12/2/91), and 

• Assistant Superintendent for Secondary 
Education (12/3/91). 
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The comments of each group of reviewers were 
recorded and reflected on a facing page of each 
succeeding draft of the format for the Profile. 
Review was largely completed by December 1991 , 
and the attention of the DISC team turned toward 
production of the Profile by the end of February 
1992. 

Printing the Profile 

Meetings of the DISC team and others in January 
1992 firmed up details of the Profile's production. 
One important decision had to do with how the 
Profile would be printed. Four options were 
initially considered: 

1. AISD programmers writing 
print statements, 

2. A Data Services staff member creating 
templates for a laser printer, 

3. Contracting with an outside vendor to 
create laser templates, and 

4. Panting into an "exploded" format. 

Besides the tried-and-true technique of having 
programmers write programs to print out the 
output, several other innovative approaches were 
considered as print options. The second option, 
which was an extension of a procedure already 
used with the first page of the most current APR 
and with pages of the GENESYS report (see 
Attachment 1), involved creating "templates" into 
which data would be printed, much like typing onto 
an already-printed form. The advantage of tem- 
plates is their attractiveness. Templates in use in 
other reports utilize varied font sizes, shading, 
reverse fonts, and other design features which 
enhance the readability and the "look" of reports. 
The disadvantage of templates is that a' special 
Xerox programming language is required to create 
them, and only one AISD staff member is trained 
in the language. Given the size of the task and the 
burden on one individual — dozens of pages were 
projected — AISD could have contracted with a 
commercial vendor to create the templates, but cost 
(in the thousands) was a deterrent to selecting 
this option. 

Another option considered was using the main- 
frame laser printer to print onto 11 x 17 inch 
paper. This option was attractive because it 
resolved the difficulty of printing a great many 
numbers close together on a page. If a template 
were used, the printing tolerance sometimes would 



be very fine. Printing into an "exploded" format 
would afford a wider margin for error. Reduced, S 
1/2x11 inch copies could then be made of the 
printed, ledger-sized pages. One disagreeable facet 
of this approach was the amount of paper handling 
that would be required to transform the oversized 
pages into standard output. 

A fifth option was put forward which involved the 
use of a Macintosh PC to create the profile pages. 
Data would be downloaded from mainframe files 
and funneled through the PC, which would send 
the pages to a laser printer to be printed. Down- 
loaded data would be stored in the hard disk of the 
PC. The advantage of this option is essentially the 
power and versatility of desktop publishing — the 
profile pages could be designed to be very attrac- 
tive. The main disadvantage of this approach had 
to do with the limitations of the PC and of the 
printer. Because of the large number of data fields 
(potentially several thousand per page) to be stored 
and retrieved, the speed with which the 
microcomputer's CPU could respond would be 
unacceptably slow. A related problem was the 
printing time involved. Because each page could 
take minutes to be assembled and printed, and 
thousands of pages were to be printed (at about 
eight pages per minute), printing through a PC 
constituted a major bottleneck. The time factor and 
other, unresolved technical questions, such as what 
software would be needed to create the interface, 
rendered this option infeasible. 

In the end, option 1 was selected, to have program- 
mers write print statements dictating the printing of 
the output, and printing 81/2x11 inch pages using 
the mainframe laser printer. 

Megafile 

Several other decisions were made in January 
meetings which had important consequences for 
creating the Profile. One of the most significant 
was the decision to create a single disk file contain- 
ing all of the data needed to print the Profile. This 
file, termed Megafile, was to become the perma- 
nent, on-line file envisioned as the basis for all 
future profiles, centrally generated at first, later by 
schools querying downloaded portions of the file. 
It was dubbed Megafile in humorous tribute to an 
earlier longitudinal database, Big File, whose size 
would be eclipsed by the new, hence "mega," file. 
Although size is relative depending on the com- 
puter system, at one point Megafile had grown so 
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large that one segment (containing records of test 
scores) required more than 32,000 kilobytes of 
storage space, which exceeded the capability of the 
system's utilities to handle it. The segment was 
pared down to a size the utilities could handle by 
leaving out a year for which there were as yet no 
data, but this was a short-term solution which left 
the problem to be resolved at a future date. At 
completion of the Profile, Megafile was allocated 
12,768,000 bytes and was stored on 27 cylinders. 

A copy of the Megafile file format is Attachment 2. 

Population versus Group Percentage 

In a DISC team meeting on January 8, .1992, a 
decision was made which had some rather bother- 
some, though ultimately productive, consequences 
for producing the Profile. The decision was that 
the percentage for "all students" would be 100% 
and that percentages within subgroups would sum 
to 100; in other words, for a given indicator, the 
percentages of males and females would add up to 
100, likewise the percentages of Hispanic, Black, 
and Other students, the percentages of 9th, 10th, 



1 1th, and 12th graders in high school, etc. The 
subgroup "low income'* was an apparent exception 
because the percentage of low-income students 
could be less than 100, but the rule did in fact 
apply, because even though the counterpart to low 
income, "not low income," would not be printed, 
the two categories if added together would sum to 
100. 

This ostensibly logical decision soon proved 
troublesome far beyond its apparent importance. 
One difficulty lay in the comparison with the 
District, in the "diff. from DisL" statistic. When 
the subgroup statistic for the District was sub- 
tracted from the corresponding statistic for a 
school, the resulting difference was sometimes 
very peculiar. On inspection, what became evident 
was that the school and the District statistics were 
not really colorable. What was going on might 
be described as a kind of "range" problem — on a 
given indicator, the District has more "range" than 
the school; that is, the District's distribution is 
based on all the students in the District rather than 
on the smaller number of students at the school. 
This range differential is particularly evident when 



Figure 1 

Example of Population Percentage 



To calculate the ethnicity % and the difference from the district, 

use the following method: 

Example: Hispanic otudents Retained-Actual/FaN 



Anderson High School 



90-91 



Rir 



91-92 



Retained-Actual /Fall 


* 


Pop 

% 


Diff. 
f r om 
Dist. 






Diff. 
Dist. 


AH Students 


168 


100 




4321 


60 


-99 


Hispanic 


93 
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4321 


60 
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Black 
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60 


-99 


Other 
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60 


99 
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60 


-99 


Male 
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99 


N$21 


60 


-99 


Female 


4321 


60 


99 


43K, 
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-99 


Low Income 
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60 


99 
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Grade PK 
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99 


4321 
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Grade K 
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Grade 1 
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60 
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60 


99 
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-99 


Grade 8 
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60 


99 
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60 


-99 


Grade 9 


4321 


60 


99 


4321 


60 


-99 


Grade 10 


4321 


60 


99 


4321 


60 


-99 


Grade 11 


4321 


60 


99 


4321 


60 


-99 


Grade 12 


4321 


60 


99 


4321 


60 


-99 



# of Anderson 
Hispanlcs Retained-Actual 

# of Anderson 
Students Retained-Actual 

93/168 = 55% 



*% of Anderson Hispanics 
Retained Actual (%A) 



# of District 




Hispanlcs Retained-Actual 
# of District 

Students Retained-Actual 


=% of District Hispanics 
Retained-Actual(%B) 


1323/2851 » 46% 




Difference from District = 


%A-%B 
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comparing percentages by grade level. Because 
District percentages arc distributed across 14 grade 
levels, grades prckindergarten (prc-K) through 12, 
and school percentages were distributed across 
eight grade levels, grades pre-K through 6, at most 
(four at the high school level), the comparison at a 
given grade level is likely to be unequal. In effect, 
the magnitude of the difference between school and 
District statistics was dictated by the range, rather 
than by the respective shapes of the District's and 
school's distributions on the indicator. Even for 
subgroups where the number of subgroup elements 
was the same (e.g., ethnicity), the District's distri- 
bution could differ greatly from the distribution at 
the school. 

In a sense, the comparison was really one of the 
respective demographics of the school and the 
District. For example, on the indicator of student 
discipline, in a school whose student body was 
made up largely of Hispanics, the difference from 
the District could be a large negative number, 
suggesting incorrectly that the Hispanic students in 
the school were disciplined at a much higher rate 
than in the District as a whole, rather than that the 



percentage of Hispanics at the school was much 
larger than in the District, and therefore the number 
of Hispanic students available to be disciplined in 
the school is higher than in the District. 

Another difficulty had to do with the meaning of the 
statistics. What did it mean, on the indicator of 
student retention, for example, if 40% of the 
students who were retained were Hispanic? A 
more meaningful statistic for most users of the 
Profile would be the percentage of the Hispanic 
students who were retained. It became evident that 
the root of the difference between these two 
statistics was which number was selected as the 
divisor. If division was by "all students" rather 
than by the number of students in the subgroup, 
then subgroup statistics are a proportion of the 
population under consideration (and percentages 
sum to 100). On the other hand, if division is by 
the number of students in the group under consider- 
ation, subgroup percentages do not sum to 100. By 
way of explaining and formalizing the distinction 
between these statistics, the terms population 
percentage and group percentage, respectively, 
were adduced. 



Fkj ,t 

Example of Group Percentage 



To calculate the ethnicity % and the difference from the district, 

use the following method: 

Example: Hispanic Students Not Disciplined 



Anderson High School 



Students 



90-91 



Rir 



91-92 



pllned 


# 


Grp 

% 


Diff. 
from 
Dist. 




■""% 
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60 
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-99 


Low Income 


4321 


60 
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Grade PK 
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Grade 1 


4321 


60 
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Grade 5 


4321 


60 


99 


4321 


60 
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# of Anderson 
Hispanics Not Disciplined 

# of Hispanic Anderson 
Students 



% of Anderson Hispanics 
Not Disciplined (%A) 



# of District 

Hispanics Not Disciplined 
#of Hispanic District 
Students 



•% of District Hispanics 
Not Disciplined (%B) 



Difference from District = %A-%B 
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Attachment 3 is a set of notes and definitions for 
the Profile. Pages 3 and 5 of Attachment 3 provide 
definitions of population and group percentages. 
Figures 1 and 2 illustrate and explain the difference 
between the percentages using retention and 
discipline as examples. If the number of Hispanic 
students who were retained at a school is divided 
by the total number of students at the school who 
were retained, the result is the percentage of the 
retainees who were Hispanic, a population percent- 
age. If the number of Hispanic students who were 
retained at a school is divided by the Hispanic 
students at the school, the result is the percentage 
of Hispanic retainees, a group percentage. 

Once these concepts were defined, even though 
production of the Profile was well underway, the 
executive director instructed that the percentage 
statistics to be reported be reexamined and the 
appropriate statistic, properly labeled, be reported. 
At first it appeared as if the group percentage 
should be the appropriate statistic to report for all 
indicators. One reason for its apparent preferability 
had to do again with meaning. With a population 
percentage, because both the totals for a school and 
for the District ("all students") are 100%, the 
"difference from the District" is always zero and 
therefore meaningless. This peculiarity notwith- 
standing, on second examination the indicator 
"student demographics" proved to be an important 
instance in which population percentage was the 
more appropriate statistic. When considering the 
percentages of males and females or the percent- 
ages of Hispanic, Black, and Other students in a 
school, the user of a profile expects the subgroup 
percentages to add up to 100. Hence, both group 
and population percentages were included in the 
Profile. 

Programming the Profile 

A group of nine AISD programmers was assigned 
the task of performing the programming necessary 
to produce the Profile. At a meeting on January 22, 
1992, the programmers received the latest draft 
format for the Profile and a timeline calling for 
completion of the Profile by February 28. The 
programmers were assigned either to write data to 
Megafile from other files or to print the profile 
pages. One of the System wide Evaluation evalua- 
tion associates was assigned as interface to the 
programmers to answer their questions. The team 
leader was to coordinate the effort, act as arbiter, 
and create user documentation (see Attachment 3). 



Several important guidelines for producing the 
Profile were enunciated at this meeting: 

1. As much as possible, programmers would 
use data from the Public Education 
Information Management System 
(PEIMS) files as the basis for the statistics 
to be printed in the Profile. 

2. "Double bump" when updating informa- 
tion where three years are given, meaning 
that the most recent year's information 
should always be stored in the same 
place — call it position 1 — the next most 
recent in position 2, and the oldest in 
position 3. Each time a new year's 
information were added, the previous 
information would be "bumped"— the new 
information into position 1, the position 1 
information to position 2, position 2 to 
position 3. 

3. All of the printing would be accomplished 
through programs written with Statistical 
Analysis System (SAS) software, rather 
than in COBOL. 

4. Zeros (O's) would be loaded into all 
numeric fields by way of initializing the 
fields and as placeholders over which 
actual data would be written. 

5. For the sake of uniformity and ease of 
printing and pagination, every page of the 
Profile would be printed for each school, 
even if no information for the school were 
present — e.g., course grades for an el- 
ementary school. 

6. Documentation would be placed on line in 
a common library. 

Over the ensuing month, the programmers worked 
very diligently to bring the Profile to completion. 
Numerous difficulties (see below) and questions 
over definitions of variables arose (e.g., see "Popu- 
lation versus Group Percentage") which slowed the 
effort, and concerns were expressed about meeting 
the February 28 deadline for producing the Profile. 
The interface provided by the Systemwide Evalua- 
tion evaluation associate and, to some extent, the 
team leader, which was characterized by a flexibil- 
ity toward problem solving and a sympathetic 
understanding of the magnitude of the task given 
the strict deadline, proved critical to keeping the 
enterprise underway. 
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Difficulties in Producing the Profile 

Some of the difficulties stemmed from decisions 
made in the January 22 meeting whicn had to be 
reconsidered. Others were rooted in differences in 
expectations for the final product. 

In light of the potential number of blank pages that 
would be printed, the executive director rescinded 
the decision to print every page for eveiy school 
and directed that totally blank pages should be 
suppressed in the printing. One consequence of 
this decision was that pagination could no longer 
be accomplished as simply. The agreed-upon 
pagination scheme was to print school number- 
page number (e.g., 002- ! !), starting over at page 1 
for the first page of each school. With a varying 
number of pages per school, pagination now 
seemed to require a complicated table lookup, and 
given the relative unimportance of page numbers 
compared with the other Profile information to oc 
assembled, the necessity for programmers to print 
page numbers was questioned. One alternative 
proposed was to have temporary clerical staff type 
page numbers on the bottom of the Profile pages 
when they were printed. 

Another issue arose over the decision to write zeros 
into numeric fields. If actual numbers were not 
written over the zeros, the zeros rather than blanks 
would be printed on the Profile pages. The execu- 
tive director's and team leader's preference was 
that zeros that did not have any true meaning, i.e., 
that did not represent a genuine zero quantity of the 
indicator, be blanked out and not printed. The 
programming difficulty in accomplishing this, 
however, was in distinguishing between a true zero 
and a mere placeholder. Unless someone could 
make this distinction by inspection beforehand, the 
programmers were at a loss for a means to ensure 
that only true zeros would be printed. 

Another printing issue not completely resolved was 
the orientation of the Profile pages. The executive 
director's preference was for all pages to be in the 
"profile" orientation, the customary book-style 
layout. The quantity of information to be reported, 
however, forced an accommodation to the "land- 
scape" orientation for some pages. Turning pages 
sideways had the consequence, in turn r of altering 
the location where the page number was printed 
from the bottom center to the center of the right 
margin, an undesircd nonuniformity. 



A follow-up meeting on February 24 resolved mos: 
of these issues: 

1. Three patterns of Profile pages were to be 
printed, one each for schools w ith grades 
K-6, grades 6-8, and grades 9-12. These 
patterns could be identified beforehand, 
and pages could be paginated appropri- 
ately. Some blank pages would be printed, 
e.g., test scores for grade 6 for elementary 
schools which did not have a sixth grade, 
but fewer blank pages would be printed 
than if one pattern were employed, i.e., 
print every page for every school. 

2. Page numbers would be printed by pro- 
grammers in the school number-page 
number format, rather than typed onto 
Profile pages after printing. 

3. Page numbers would be printed at the 
right-hand margin on landscape pages but, 
in future Profile runs, placed at the 
bottom center. 

Despite these difficulties, the Profile was printed 
on schedule the weekend of February 28, 1992, 
and after internal review was copied and dissemi- 
nated to campuses and administrators the second 
week of March. 

Attachments 4, 5, and 6 are sample profiles for an 
elementary, middle school, and high school, 
respectively. 

District Profile 

In the October 1 meeting, the team decided to place 
District information on Megafile but not to print it. 
The hurdle needing to be overcome with the 
District profile was the format in which it would be 
printed. Printing "difference from Dist." statistics 
did not make any sense and argued for redesigning 
the Profile's format for District statistics. With 
priority being given to printing the school profiles, 
and no immediate need for a District profile, 
printing of the profile was deferred until 
the next cycle. 
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Student Profile 
Rationale 

The individual student profile is the answer to the 
long-sought, often-requested student information 
screen, an on-line computer "file" containing 
comprehensive information — sometimes described 
as "everything you ever wanted to know" — about a 
student which could be accessed by personnel on a 
campus or in administrative offices. Prospective 
users of the screen wanted to be able to view on- 
line information about a particular student from 
interactive disk files maintained on the District's 
IBM 4381 mainframe without having to terminate 
access to one file before accessing the next; they 
wanted, in essence, to be able to "swim" through 
the files without being encumbered by having to 
key in file names, the student's identification 
number, and passwords. Questions of access to 
confidential information aside, the task of connect- 
ing dozens of files was a technically feasible, 
though laborious, project, which had never re- 
ceived sufficient priority to see it realized — until 
DISC. 

CICS Meets EXPRESS 

Initial planning for the student profile by the 
System wide Evaluation e valuator was along the 
lines of another interactive file — a database cus- 
tomer information control system (CICS) in IBM 
terminology — with multiple "pages" (screens) 
containing the desired information through which 
the user could browse. Similar (though not as 
extensive) CICS files were already in use in AISD, 
and another file would merely be a more elaborate 
version of existing applications. However, the 
executive director of DMI furnished an alternate 
vision of the student profile, which grafted the 
home-grown notion of a student information screen 
with a national effort for standardizing electronic 
data exchange. Enter ExPRESS, Exchange of 
Permanent Records Electronically for Secondary 
Students. 

The executive director envisioned the student 
profile as the "flip side" of the electronic transfer 
of student transcripts, from university to university 
and from school systems to universities. AISD had 
already, in fact, been successfully transmitting high 
school student transcripts to The University of 
Texas at Austin for several years. Now the 
ExPRESS effort was in need of a print format for 



hard copy, that is, how the data transmitted elec- 
tronically would appear when printed on paper. 
Creating this print format was the first step toward 
realizing a student profile because a single format 
could be used both for data extracted from AISD 
files and for data transmitted to AISD electroni- 
cally via ExPRESS (see Figure 3). In other words, 
whatever the source of the information about the 
student, a hard copy of the student's profile could 
be printed. The executive director decided against 
an on-line display file until the system for printing 
the hard copy student profile could be implemented 
and the demand for student profile information by 
campuses evaluated. 

Whether the outcome was to be the successful 
transfer of student data or the production of a 
student profile from AISD files, the key was 
programming, as illustrated in Figure 4. 



Figure 3 

Commonality of AISD Data and ExPRESS 
Data Print Formats 




Designing the Profile 

Accordingly, in October 1991, a programmer was 
assigned to work on the ExPRESS "side" of the 
project, while the Systcmwidc Evaluation evaluator 
set about drafting the print format. Working from 
an extensive set of ExPRESS specifications, the 
evaluator was charged with including in the format 
all of the data elements present either in the 
ExPRESS specifications or in AISD files and 
records, which overlapped considerably but not 
completely (see Figure 5). The resulting seven- 
page format, completed in mid-November 1991, 
enabled the programmer to meet a mid-January 
deadline for completing the programming needed 
to demonstrate ExPRESS at a nationally attended 
meeting on February 15, 1992. At this meeting, 
data were transmitted electronically and were 
printed out using the AISD-developed print format. 
(Prior to the meeting, a "dummy" print of a student 
profile with all of the information shown ran to 25 
pages!) 



FIGURE 5 

Overlap of ExPRESS Specifications and 
AISD Files and Records 



AISD 
Filts, Record: 




express * 

Format Elements 



Figure 4 

The Role of Programming in Unifying the ExPRESS and Individual Student Profile Efforts 




To draft the print format, the evaluator examined 
the displays of 27 extant C1CS screens representing 
student data in the areas of: 



• Achievement, 

• Attendance, 

• Chapter 1 eligibility, 

• Demographics, 

• Discipline, 

• Elementary gifted, 

• Family members, 

• Grade history, 

• Grade reporting, 



• Graduates, 

• Guidance counseling, 

• Home country, 

• LEP status, 

• Lunch applicants, 

• Migrants, 

• Special education, and 

• Vocational education. 



Data elements from these screens and from the 
ExPRESS specifications were incorporated into a 
print format which was later elaborated by the 
programmer, who was able to access the disk 
source files on which the CICS screens draw. 

Programming 

In April 1992, after the school profile was com- 
pleted, work on the student profile resumed. The 
Systemwide Evaluation evaluator drafted a new 
timeline for DISC activities which called for 
putting thcindividual student profile on line by the 
end of the school year, June 1. On April 10, 1992, 
the evaluator drew up a set of specifications for 
producing the student profile. While the program- 
mer had performed the necessary programming on 
the ExPRESS side of the project, the programming 
to access local files had still to be completed. The 
programming required for creating a student profile 
was conceptualized in the timeline and the specifi- 
cations as involving essentially two processes: 

• Setting up an on-line mechanism whereby 
the students for whom a student profile 
was desired could be designated, and 

• Accessing multiple virtual storage access 
memory (VSAM) files to gather the 
information to be printed on the profile. 

The mechanism for identifying the students was 
termed the "trigger" and was described in the 
specifications as "a CICS file into which student 
ID's are entered, job control language (JCL) is 
assembled, and the job is entered into the job 
stream." As outlined in the specifications, when a 



correct ID is entered from an authorized terminal, 
VSAM files, i.e., on-line disk files, would be 
accessed and a profile printed. Programs needed to 
be written to: 

• Create the "trigger," 

• Access VSAM files, 

• Interface with the "trigger," and 

• Print the individual student profile. 

In the interests of time and staff development, the 
task of creating the "trigger" was assigned to a 
second programmer, who was furnished wiih 
separate, detailed specifications (Attachment 7). 
The first programmer continued working on 
programs to extract information from files and to 
print out the information in the previously devised 
format. The two programmers collaborated to tie 
the "trigger" to the file accessing segment. 

Both the programming for the "trigger" and the 
accessing/printing programs (by far the larger task) 
have been completed. The programmer woriting 
on them had to work to knit together several "loose 
ends" left by the print format since the fomiat 
reflected the data about a student that it would be 
desirable to have, whether or not those data cur- 
rently exist on an accessible file. A sample of the 
individual student profile is Attachment 8. 

At-Risk Status 

One of the areas in which new programming was 
needed was student at-risk status ("at risk" refer- 
ring to the risk of dropping out of school). The at- 
risk status of AISD students is saved each year on a 
computer file, but it was not available on a disk 
file. For ease of access for the student profile and 
for other reporting purposes, the evaluator pro- 
posed that a position (field) on the Student Master 
File (SMF) dedicated for use in identifying 
high-risk 

students but not being used be redefined for use in 
identifying at-risk students. This proposal was 
implemented in June 1992. The SMF was updated 
with new information in the newly dedicated at- 
risk field, specifically, "yes" or "no" (Y/N) or"H" 
(high risk), based on the codes stored in the 1990- 
91 at-risk files (elementary and secondary). 



Other Programs 



The following persons arc not authorized access to 
on-line computer files of test results: 



ERLC 



Another area of new programming arising from the 
task of reifying the print format for the student 
profile concerned "other" programs. Besides 
reflecting the student's status with respect to 
participation in special education, bilingual, 
Chapter 1, Chapter 1 Migrant, or giftcd/talcnicd 
programs, the student profile would ideally indicate 
whether the student has participated in other types 
of programs, e.g., dropout prevention, drug preven- 
tion, or tutorial programs. At this time, however, 
information about participation in these programs 
is not readily accessible. To remedy this defi- 
ciency, the evaluator proposed that a disk file be 
created into which numerous GENESYS files 
would be loaded (see Attachment 1). The proposed 
file would contain information for multiple pro- 
grams for the last three years and would be a ready 
source of "other" program information for the 
student profile. The proposal is under study by the 
programmer supervisor of student applications. 

Confidentiality 

While creating a student profile which brings 
together information from numerous central 
computer files was technically possible, and 
desirable from the standpoint of potential users of 
the information, the question of access to confiden- 
tial student information had to be addressed. Only 
persons with "legitimate educational interests" 
(District policy) could have access to individual 
student information. The same criteria for authori- 
zation and access were applied to IPRO, the CICS 
screen through which the student for whom a 
profile was needed was designated, as to other 
CICS screens which displayed confidential test 
information on-line. According to District policy, 
only the following administrative and professional 
personnel are authorized to access on-line com- 
puter files of test results: 

• Principal, 

• Assistant Principal, 

• Helping teacher, 

• Counselor, and 

• Registrar. 

Other professional or clerical personnel employed 
on a campus may be authorized access to on-line 
computer files of test results at the discretion of the 
principal, who is responsible for ensuring the 
confidentiality of the information. 



• Community volunteers 

• Students, including aides 

At a campus, authorized personnel may look a: tesi 
results, or request a student profile, only for 
students in their own school. The student must be 
shown on the Attendance File as attending that 
school before the student's records can be ac- 
cessed. 

A number of security precautions already in effect 
for users of the District's IBM mainframe com- 
puter extend to IPRO as well. Users must supply 
authorized passwords in order to "sign on" to the 
computer. The passwords themselves determine 
the level of access to on-line files. Once signed on, 
all users are presented with a text screen warning 
them about unauthorized use of the computer and 
data stored on the computer. 

Besides these security measures, two additional 
levels of security help to ensure the confidentiality 
of individual information: 

1. A screen which appears before the first 
menu warning the user against improper 
access, and 

2. The requirement of a password to pass 
beyond the first menu. 

Only authorized personnel may receive the pass- 
word. These personnel must keep the password 
secure at the risk of losing the authority to access 
on-line files. 

Several other procedures were also devised to 
protect against unauthorized access to confidential 
student information: 

1. The person requesting a student profile 
must specify the student by AISD student 
identification number, which in itself is 
confidential, rather than by name. 

2. The person requesting a profile must 
supply a name, title, and phone number by 
typing them onto the IPRO screen. 

3. The student ID number and name of each 
student for whom a request is made for a 
profile, along with the date of the request, 
and the name, title, and phone number of 
the requester arc logged by the central 

1 9 computer. 
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4. The Student Profile Request Log is 
forwarded to an ORE administrator who 
monitors the requests for appropriateness. 

5. A cover sheet with "confidential'* printed 
large and the name of the requester (but 
not the student) is placed on top of the 
printed student profile. 

6. The student profile is sent through school 
mail directly to the requester. 

Although all of these procedures do not insure the 
absolute confidentiality of the information in the 
student profile, particularly after it is in printed 
form, they do operate to protect the information 
from casual disclosure and they emphasize the 
confidential nature of the information. In the rt nd, 
as with all confidential student information, the 
best protection against exposure resides with the 
responsible use of the information, and secure 
disposal when no longer needui, by District 
personnel. 

INCREASING DATA ACCESS AND 
ANALYSIS CAPABILITIES AT THE 
CAMPUSES 

Hardware 

Clearly, in order for campuses to become frequent 
producers of campus-level information, a great deal 
more computer equipment has to be present on the 
campuses. Not just any equipment can be pur- 
chased, however, without perpetuating the current 
situation in which neither hardware nor software 
are standard across the campuses, thwarting 
attempts to routinize common applications. At- 
tachment 9 (dated August 29, 1991) specifies 
hardware standards for elementary campuses. 

Since fall 1991, there has been a new development 
which will help guide future expansion of the 
District's computer capabilities. With guidance 
and help from IBM staff, DMI staff have been 
working to plan an AISD Information Systems 
Architecture (see below). 

A budget request for an additional PC and printer 
for each elementary campus was submitted for 
inclusion in the proposed 1992-93 budget but was 
deleted early on in budget deliberations. The 
School Board did approve a DMI proposal to use 
available telecommunications and computer 
maintenance funds to connect elementary schools 
to the mainframe computer system using the 



institutional cable network (INET). This connec- 
tion will give elementary schools the same direct 
access to the mainframe enjoyed by secondary 
schools and eliminate the dial-up modems and lines 
they have been using. Installation of the lines, 
modems, and CRT terminals will occur in summer 
1992, with adjustments to be made on request in 
fall 1992. 

Software 

Beta Testing 

In addition to hardware, in trying to accomplish the 
goal of increasing access and analysis of data at the 
campus level, a careful study of available software 
and the accompanying hardware it requires is 
essential. Software publishers are constantly 
striving to develop products that will be both 
beneficial and manageable for the end user. In this 
vein, software publishers have over the years 
turned to the users for feedback when writing new 
software or upgrading existing software. 

When software development is nearing completion, 
prospective end users are sought to critique and test 
the software in a working environment. This 
process is known within the software industry as 
beta testing. Throughout beta testing, end users 
can comment on different aspects of the software's 
performance. Beta testers are encouraged and 
expected to: 

• Become familiar with and use the program 
extensively to document any problems or 
"bugs" that could inhibit the program from 
running either properly or at all, 

• Comment and document likes and dislikes, 

• Envisage features that could enhance the 
use of the product to others, and 

• Make remarks on overall value as to how 
well the software meets its intended need. 

Beta testing can be a very worthwhile experience 
for both parties (software publisher and beta tester). 
The publisher obtains firsthand knowledge of the 
worth of the product in a +rcal world+ environ- 
ment, whereas the beta tester gets to assist and 
provide input in the development of new and 
leading edge technologies. 
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Test Reporting Management System™ 
(TRMS™) 

In January 1992, the Office of Research and 
Evaluation consented to participate in a beta testing 
project for the Psychological Corporation. The 
software ORE was asked to evaluate was the Test 
Reporting Management System (TRMS). 
The entire process took about three months from 
start to finish. 

ORE was asked to document responses throughout 
the process in the form of resporises on question- 
naires provided by the publisher. The first ques- 
tionnaire dealt with initial impressions about the 
overall packaging of the product, the second, 
installation and first attempts at using the program. 
The third and final questionnaire was an in-depth 
evaluation of TRMS after having used it for 
several weeks. 

Pending an evaluation of the final release of the 
software, it is not yet possible to make a decision 
as to its value to the District, but a first impression 
was that it could be very useful in managing 
test reporting. 

Ready Graphs PLUS 

ORE was provided with a working copy of the 
Ready Graphs PLUS from the Psychological 
Corporation to review. Ready Graphs is a software 
product that contains preformatted graphs for an 
individual school district based on the district's test 
scores. The charts are easily producible with a 
minimum amount of work. Although the product 
was able to provide much useftil information well 
displayed in graphs, it was decided that the District 
and the campuses would benefit from a program 
that was more versatile and allowed users more 
control over the manipulation and presentation of 
the data. 

Management Software 

For some time, the executive director has sought 
some software to aid in planning and managing 
complex projects — projects like DISC, in fact. 
Although such traditional planning tools as PERT 
and G ANTT chaiting are helpful, these techniques 
lack the utility and versatility of sophisticated 
software. With an eye toward expediting DISC 
itself, and another toward finding software which 



could become standard for the District, members of 
the DISC team reviewed a promising product b^ 
Symantec called On Target. The main drawback of 
On Target, with respect to becoming a District 
standard, was that it requires the use of Microsoft 
Windows, and Microsoft Windows uses more 
storage space than desired, according to AISD's 
assistant director for programming. 

The executive director purchased and is using 
Microsoft Project for Windows 3.0. Whether this 
software will be selected as the standard manage- 
ment software for the District is undetermined. 
Like On Target, Microsoft Project for Windows 
uses Microsoft Windows and thus shares that 
disadvantage. 

Simple Applications 

Student/Parent Addresses 

One of the first-year objectives of the DISC project 
was to identify and furnish to campuses simple 
applications which be used immediately. One such 
application was developed by DMI's Data Process- 
ing/Interface office in response to numerous 
requests from campuses for student mailing labels 
and rosters of student membership. Although 
providing this information is not difficult, the 
volume of requests received disrupted the flow of 
work on other, larger projects. Therefore, the 
prospect of decentralizing this process became very 
attractive not only to central staff but also to local 
campus staff as well. 

To give the schools more direct access to this 
information, Data Processing/Interface set up a 
system whereby school staff can request student 
demographic data for their campus. A data inter- 
face person then downloads the information from 
the mainframe onto a PC diskette. Once the 
diskette is completed it is sent to the school for its 
use. Data Interface provides the schools with the 
raw data only, not the actual software. The schools 
need to have the software to manipulate the data. 
Each campus is responsible for investing in the 
software that best met its needs (database, word 
processing, specialized label making programs 
etc.). In this way, all the information is readily 
available to all campus staff and can be printed 
locally without having to wait for a printout to be 
sent through the school mail. 



Already-Formatted Data Files 



Support Personnel 



For those campuses where the interest, the soft- 
ware, and the expertise exists to manipulate data 
provided on diskette, ORE has been furnishing 
customized files converted into American Standard 
Code for Information Interchange (ASCII). This 
practice requires that a programmer perform the 
file-building operations using the mainframe 
computer and download the file to diskette. For 
example, one high school was furnished with a file 
in ASCII containing the names of its students, their 
ethnicities, parents' names, and telephone numbers 
(information not routinely available from Data 
Interface). Using its own software, the school can 
manipulate the coded data to create a school 
directory, mailing labels, etc. 

The Longhorn Project 

In fall 1991, members of the DISC team reviewed 
The Longhorn Project in Chemistry for possible 
implementation in District high schools. The 
Longhorn Project, developed by faculty members 
at The University of Texas at Austin (the "Long- 
horns"), is an integrated, computerized system 
which generates, and machine scores, sets of 
homework assignments, tests, and examinations 
individualized for each student. The system 
utilizes an extensive database of chemistry ques- 
tions, organized by concepts, that has been devel- 
oped over the past 10 years by UTs Chemistry 
faculty members for their own use. After being 
field tested at Anderson High School during the 
spring 1991 semester, The Longhorn Project was 
offered to the District as a subscription service. 
However, the cost of the services — $1 per week per 
student, totaling $5,400 for 150 students per school 
year, plus the cost of courier service between UT 
and high school campuses for pickup and delivery 
of printouts — was too expensive for Districtwide 
implementation. Nonetheless, this computerized 
system, which has the potential for saving teachers 
time and reducing their paperwork, while increas- 
ing individualized instruction, is the sort of auto- 
mated application which needs to be fostered 
within AISD at the campus level. 

Staff Training 

Although the importance of training has been 
reaffirmed in discussions with administrators, 
training for staff remains a goal for the second year 
of the DISC project. 



Consideration of what support services arc needed 
and which personnel would provide them remains 
to be addressed in the second year of the DISC 
project 

DIRECTIONS FOR THE FUTURE 

Information Systems Architecture (ISA) 

The path by which the second goal of the DISC 
project, that of increasing the data access and 
capabilities at the campuses, will be realized is via 
a districtwide plan for technology and information 
management. 

In April 1992, the Austin Independent School 
District began work on a project with districtwide 
ramifications in technology known as Information 
Systems Architecture (ISA). The planning and 
building of this architecture was overseen and 
directed by IBM Information Systems Architecture 
specialists in partnership with AISD staff. Funding 
for this endeavor was supplemented by Project A+. 

AISD's ISA specifies standards and principles 
upon which technology projects, packages, and 
future applications will be based. The idea is that 
in the future, when someone in AISD has a project 
or purchase to make, the question that must be 
answered is, "Will this function within AISD's 
overall technology architecture?". 

AISD's objectives for creating the Information 
Systems Architecture are as follows: 

1. Create an architecture which can be used 
by instructional environments, campus 
management, and central support services 
to guide the design of systems and the 
selection and deployment of Information 
Technology assets. 

2. Establish standards to be followed. 

3. Establish clear performance levels for 
Information Technology systems. 

4. Document architectural principles used to 
guide Information Technology decisions. 

5. Minimize politics associated with isolated 
decision making. 



6. Document a technology strategy. 

7. Summarize the current Information 
Systems environment. 

8. Establish a computing model for schools. 

9. Establish criteria for selecting products, 
removing the burden from non Informa- 
tion Technology literate personnel. 

More information about AISD's ISA may be found 
in Information Systems Architecture for the Austin 
Independent School District 

Clearly, AISD's Information Systems Architecture 
blends with the goal of the DISC project, to 
increase data access at the campuses while provid- 
ing the capability to analyze the data. By allowing 
the Information Systems Architecture to be fully 
implemented, the District is assured of a uniform 
structure and development of information technolo- 
gies. The ISA insures that all technologies within 
the District, both present and future, will be 
compatible and workable. The DISC project then 
has only to work within the ISA structure, and by 
tapping into the resources and information already 
collected and reported by the ISA can attain its 
goal. 



"executive summary" to the Profile has merit. 
Disaggregation of the data by ethnicity has proven 
useful, but because of requests for information 
about Asian students, future Profiles will break 
down data by five ethnic groups instead of three. 
A central user of the individual student profile has 
made suggestions for additions, and specifications 
will soon be drawn up for a programmer. Two 
high schools believe they have the computer 
hardware, software, and trained personnel to begin 
receiving data sets on diskette, and a programmer 
is readying a database. 

The first step has been a good one, but it is only a 
first step, and many other things need to occur to 
provide better end user computing services, to 
implement new tools, techniques, and processes 
that allow users to access and use information, and 
to develop and use information bases of their own. 
More hardware needs to be acquired, more soft- 
ware as well, and staff training and support will 
need extensive investment. With continued effort 
and user interest, we can go where no profile has 
gone before. 



CONCLUSIONS 



After the first year of the project, it is reasonable to 
ask, "How far along are we?" How much progress 
has been made in realizing the goals and objectives 
of the DISC project? The answer, basically, is that 
we have taken a good first step. School profiles 
have been redesigned and consolidated. A new 
student profile is on-line and being used. Simple 
applications have been placed in the hands of users, 
and some important software has been reviewed 
and tested. Finally, an architecture is being devel- 
oped which will provide the framework for realiz- 
ing more of the goals of the project. 
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Reaction from the field, from campus staff and 
others, has been generally positive. Many informa- 
tion needs have been met by directing persons with 
queries to the Profile. One persistent request, 
toward which efforts arc now underway, is for a 
shorter version of the Profile, one which, as one 
central administrator so blithely put it, would 
contain "just the important information." The 
problem of defining what that was for ill audiences 
did not phase him. Nonetheless, the notion of an 
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Some definitions provided are from or adapted 
from: 

Blissmer, R. H., & Aldcn, R. H. (1989). Working 
with computers . Dallas: Houghton Mifflin Com- 
pany. 

Application. A particular task for which a com- 
puter program is written. 

Byte. A unit of storage that can hold one character 
of information. A kilobyte is 1,000 bytes. 

CICS. Customer information control system. 
IBM terminology for an on-line disk file which 
allows the user to seek, and sometimes change, 
information. 

COBOL. Common business oriented language. A 
standardized business language for programming 
a computer. 

Data. The raw facts that are used to create 
information. 

Database. A collection of various categories data, 
organized according to a logical structure. 

Desktop publishing. The use of personal comput- 
ers and page composition software to prepare and 
print typeset- or near-typeset-quality documents. 

Disk. An information-storage device. A disk is a 
random access medium, which means that informa- 
tion can be retrieved from any part of it without 
having to "read" through it from the beginning, as 
is required with magnetic tape. 

Distributed processing. Information processing 
distributed among physically separate 
computer systems. 

File. A collection of logically related information. 

Format. The way information is physically 
organized on a display screen, printed page, 
or disk. 

Hard copy. Printed on paper. 

Hardware. The electronic and mechanical compo 
ncnts of a computer system. 



Information. Data organized such that Uicy can be 
used in decision making. 

JCL. Job control language. IBM terminology for 
the commands a programmer gives a computer to 
have it operate. Separate from the commands in a 
computer program. 

Laser printer. A printer that creates better than 
letter-quality printing. 

Mainframe. Room-sized, high performance 
computers, capable of running complex programs 
that would be impractical or impossible on smaller 
computers. 

MIS. Management information system. The use 
of computers and other systems to generate the 
information necessary for management to perform 
its major functions: planning, organizing, direct- 
ing, and controlling. 

On-line system. A system in which input is 
transmitted immediately from the point of origin to 
a central location for processing. 

Query. A question or request for information. 

Software. The programs that control the operation 
of a computer. 

Template. A partially completed woiltsheet 
containing text and formulas but not data. 

Utilities. Programs that perform functions required 
by many of the application programs using the 
system; for example, utilities can copy, rename, 
and delete files. 

VSAM. Virtual storage access memory. VSAM 
files are on-line disk files. 
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Elementary Campuses 

Attachments 2-9 are available on request from the 
Office of Research and Evaluation, 1111 West 6th, 
Austin, TX 78703-5399, (512) 499-1724, FAX 
(512) 480-9595. 
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ATTACHMENT 1 

DESCRIPTION OFAISD PROFILES 
BEFORE DISC 



Academic Excellence Indicator System (AEIS): 
AEIS, the result of a mandate from the Texas 
Legislature calling for a comparison of "the 
performance of each campus to the performance of 
campuses with similar wealth and demographics," 
is a set of indicators of the quality of learning on a 
campus and other performance standards. Every 
year, campuses receive performance evaluations 
from the Texas Education Agency (TEA). Each 
report contains two ratings. One rating reflects the 
performance of students at the campus against the 
performance of students in the 100 campuses in the 
state most demographically similar to it; the other 
rating reflects the performance of students at the 
campus against state standards. 

The eight AEIS indicators are: 

• Texas Assessment of Academic Skills 
(TAAS) performance, 

• Percent student attendance, 

• Dropout rate, 

• Enrolln. ,nt in advanced courses, 

• Expected graduation rate, 

• Percent graduates to receive advanced seal 
on transcript, 

• College admissions tests, 

• Percent of students passing all portions of 
the Texas Academic Skills, and Program 
(TASP) on first attempt. 

Achievement Profiles: AISD's Achievement 
Profiles contain summary data for the achievement 
tests, both criterion- and nonn-referenced, adminis- 
tered in the District over the previous five years. 
Norm-referenced test data are disaggregated by 
school, and within school by grade; within grade, 
data are broken down by test for the total group and 
for each ethnicity. Median percentile rank nd 
median grade equivalent (GE) scores are reported 
for each subgroup. For the total group, percentages 
of students scoring in various percentile ranges and 
percentages of students scoring at least plus or 
minus 1.0 GE from grade level are presented. 
Criterion-referenced test results are shown in terms 
of the percentage of students at each school master- 
ing each test objective and the percentage of 



students mastering each subject area. Demo- 
graphic summaries present the percentage of 
students mastering each subject area by subgroup. 

Annual Performance Report (APR): Conceptu- 
alized as a "report to the stockholders," the APR is 
an outgrowth of Texas' education reforms of the 
mid-1980s. The 1990-91 school year report was 
the seventh and last APR to be prepared. Changes 
from the Legislature and TEA have substituted the 
AEIS as the mandated report from all school 
districts in the State and require that it be used as 
formatted and printed by TEA. In the future, 
therefore, the AEIS Report will constitute the APR, 
and a Profile containing other information useful 
for schools staff will be produced (the Profile 
created as part of DISC). The Profile incorporates 
all of the information contained in the APR and 
uses some of the same format and "template" 
technology for the first page. 

Effective Schools Standards Report (ESSR): 
In 1987-88, the principals of AISD's Priority 
Schools worked with ORE to develop common 
standards which describe an effective school. 
Standards were developed for: 

• Student attendance, 

• Staff attendance, 

• Statewide test performance, 

• Local test performance, and 

• Parent evaluatioa 

The ESSR reports how well each school has met 
the effective schoo! standards and whether the 
school is "improving" based on student perfor- 
mance on the statewide test. Because it contains 
almost all of the same information, the Profile is 
intended to replace the ESSR. 

GENeric Evaluation SYStem (GENESYS): 
GENESYS is a method of streamlining data 
collection and evaluation through the use of 
computer technology. By gathering information 
from AISD's extensive databases, GENESYS 
reports the following standard information on any 
specified group of students: 
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Student characteristics, 

Achievement, 

Attendance, 

Discipline, 

Grades/credits, 

Dropouts, and 

Retainees. 



GENESYS has been used to produce a report on all 
of the District's schools, but with the advent of the 
DISC Profile, it will no longer be necessary to do 
so. 

School Characteristics and Rsnks (SCAR): 
More than five years ago, in response to the need 
for comparative school information on a wider 
range of indicators than achievement alone, ORE 
developed an cm-line computer file and accompa- 
nying reports which ranked schools on variables 
such as pupil-teacher ratio, students promoted, 
students attending college, and many others. In 
order that rankings be unidimensional, variables 
were selected which correlated positively with 
performance on standardized tests, which some- 
times led to less-conventional phrasing, e.g., 
students not in special education. As an on-line 
file, SCAR was an early forerunner of Megafile, 
which is intended eventually to be available for 
viewing on-line at the campuses. SCAR was 
updated twice annually, in the fall and in the spring 
when data became available, so that the data 
displayed on screen was always the latest available. 
Each variable was reported with the year or semes- 
ter and year it represented, so that the user knew 
the "as of 'date, a practice carried forward into the 
Profile. 

Secondary Profile: During the 1990-91 school 
year, at the request of the Division of Secondary 
Education, ORE produced a Secondary Profile 
which presented five years of data for each high 
school and middle/junior high school campus on 
the following variables: 

• Texas Educational Assessment of 
Minimum Skills (TEAMS), 

• Iowa Tests of Basic Skills (ITBS), 

• Student attendance, 

• Staff morale, 

• School climate, 

• Parent satisfaction, 

• Discipline, 

• Dropout rate, and 

• Passing grades. 



Vital Signs: Over a five-year period (1986-87 
through 1990-91), the superintendent's Cabinet 
reviewed selected management statistics on a six- 
weeks basis. The superintendent requested that 
staff develop a straightforward method for display- 
ing the statistics to facilitate the tracking of trends. 
The method developed was a multicolored chart 
which presented graphically these key management 
statistics: 

• Attendance, 

• Discipline, 

• Grades, 

• Nondropouts, and 

• Exit-Level TEAMS/TAAS. 

Vital Signs ceased to be produced in 1991-92 and 
is replaced by the Profile. 

Samples of all of these profile reports are available 
on request from ORE. 



The DISC Profile replaces the Secondary Profile. 



Handout for: Distributive Information Systems for Campuses (DISC): Going Where No Profile 
Has Gone Before . Wilkinson, Spano, Meyer, AERA, April 14, 1993 



TIMELINE OF KEY DECISIONS 



DATE 


ISSUE 


DECISION | 


September 1991 


"Periodicity" of the 
Profile 


Create a single, printed profile with | 
cells completed as data become B 
available-whenever profile is 
printed, available data are entered, 

othpr folic hlonV 


September 1991 


Medium of the Profile 


Hard copy. Explore other media in 
the future, beginning with on-line, 
interactive. 


September 1991 


Guidelines for the Profile 


• Disaggregate 

• Include statistics not on any 
existing profile 

• Give #'s aM %'s 

• Give a 2-, 3-, or 5-year historical 
perspective 

• Compare each campus to District | 
totals | 


September 1991 


Features of the Profile 


• Available on request | 

• Most current data 

• Meaningful and useful to 
somebody (as many as possible) 

• Disaggregated information 1 

• Positively stated indices, e.g., 1 
promoted instead of retained | 

• Glossary, index, table of | 
contents, definitions, formulas, | 
examples g 

• Appropriate comparisons/valid 1 
rankings j 


September 1991 


Outside review 


Review after the design stage by 
knowledgeable users, both 
individuals and existing advisory J 
committees with broad-based 
representation. 


September 1991 


Format of the Profile 


Hierarchical: area, indicator, 
subindicator, group, subgroup, 
statistic 



TIMELINE OF KEY DECISIONS (cont.) 



DATE 


ISSUE 


DECISION 


September 1991 


Length of the Profile 


As many pages as needed no matter 
how long i 


I September 1991 


Rankings 


Do not rank campuses according to 1 
statistics such as dropout rate, etc. \ 


October 1, 1991 


Major sections of the 
Profile 


• School Description 1 

• Student Information | 

• Staff Information 0 

• Finance Information fl 


October 1, 1991 


Comparative statistics- 
District, state, national 


Print only a school's differences | 
from them. Do not print a District 
profile. 


January 1992 


Printing the Profile 


Programmers write print statements 
dictating the printing of the output; 
print on 8 1/2 x 1 1 inch pages using 
the mainframe laser printer 


January 1992 


The Profile file 


Create a single disk file containing 
all of the data needed to print the 
Profile-~"Megafile" 


January 8, 1992 


Definition of "all 
students" 


For "all students" (total), the 
percentage should be 100%, and 
percentages within subgroups 
should sum to 100. | 


January 1992 


Population vs. group 
percentage 


Rescind earlier decision to have 1 
subgroups sum to 100%. Define I 
two types of percentages. Report | 
appropriate percentage statistic for 
each indicator. 


A January 22, 1992 


Programming the Profile 


• Use data from files created for 
state-mandated reporting. 

• "Double bump" when updating | 
information where three years 1 
are given. 

• write pnni programs in omo. 

• Initialize numeric fields with O's. 

• Print every paga of the Profile for 
each school, even if no 
information for a school is 
present. 

• Document in an on-line, common 
library. 
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TIMELINE OF KEY DECISIONS (cont.) 



February 24, 1992 


Printing blank pages 


Rescind earlier decision to print 
every page for every school. Print 
three patterns of Profiles, one each 

for ^rhool^ with orarifi^ K-6 fi-ft 

and 9-12. Print some blank pages 
where the data do ncc exist, but 
fewer than would be printed if only 
one pattern were used. 


tt Februarv 24. 1992 

1 1 wwl UUI y A» ■ / 1 w w 4> 


Paae numbers 

f w. y w I I w I I I ww ■ w 


Print school number-oaae number 
(e.g., 002-1 1), starting over at page 
1 for the first page of each school. 


February 24, 1992 


Orientation of the 
printed Profile pages 


While "profile" orientation preferred, 
print some pages "landscape." On 
landscane naatiS orint oaae number 

IUI lUOwMWU r %J ww, ^/l MIL ^/vlv^w 1 1 VI 1 1 wwl 

at the right-hand margin instead of 
bottom center. 


Fphmarv 1QQ? 

r cui ucji y ( «j «j *- 


Writino 0'<5 into numeric 

VV 1 llll IVJ w w III Iv 1 1 vl 1 1 Iwl 1 w 

fields 


Do not orint zeros that did not have I 

I— ' \J | | \J L w 1 1 1 1 1. i.OI Ww L 1 Id L UIU 1 1 w 1 1 IQ VC 

any meaning, i.e., represent a 
genuine zero quantity of an 
indicator. Identify beforehand and 
inform programmer. 


February 1992 


Documenting 


Write separate document, "Notes 
and Definitions." and disseminate 

%m 1 1 fc^ \f 1 1 1 II M X^l 1 s-w / 1 1 \*9 \*9 1 w 1 t 1 1 1 1 %^ V. ^> 

with Profile. 


Auaust 25 1 992 


Printina a District Profile 

1 1 II 1 11 1 IVJ w fc^ 1 w tl 1 w til w^ 111 w 


Print Profiles for each of five 

1 1 M IL 1 1 1 ■ 1 w%# 1 %SI \J %m \df 1 1 I 1 1 v 

administrative areas and for the 
District according to grade span, 
one for each area and the District | 
for grades K-6, 6-8, and 9-12-18 I 
Profiles in all. 1 


December 1992 


Footnotes 


Include footnotes defining variables 
on Profile pages. 


January 1993 


Executive Summary for 
Profile 


Create 2-page Executive Summary 
for Profile using District's previous 
Annual Performance Report as 
model. Replace previous first page. 
Print each time Profile is printed. | 
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Handout for: Distributive Information Systems for Campuses (DISC): Goinc Where No Profile 
Has Gone Before . Wilkinson, Spano, Meyer, AERA, April 14, 1993 



OVERVIEW 



PURPOSE (MISSION) OF PROJECT: 



To empower campuses to access and use 
information for decision making more effectively 



GOALS OF THE PROJECT: 



1. To redesign student, school, program, and 
districtwide profiles, and 



2. To increase data access and analysis 
capabilities at the campuses 

FIRST-YEAR OBJECTIVES OF PROJECT: • Identify software campuses can use 

• Redesign profiles 

• Redesign applications 

• Increase data access at the campuses 



PERSONNEL (THE DISC TEAM): 



Administrator (team leader) 25% 

Administrator 1 5% 

Professional 25% 

Professional 75% 

Professional 15% 

Programmer (supervisor) 15% 

Programmers (7) varied 
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OVERVIEW (cont.) 



PREREQUISITES FOR PROJECT: 



• IBM 4381 mainframe 

• Statistical Analysis System (SAS) on-line 

• COBOL 

• Mainframe laser printer 

• Multiple student and other data files 



TIME FOR PROJECT: 



5 MONTHS (first phase only) 



COST OF PROJECT: 



$48,569 (first year only) 



METHOD: 



• Design Profile 

• Write custom software in COBOL and SAS to 
extract student, staff, and financial data from 
centrally maintained District files and store on 
single, "Megafile" 

• Print Profile for each campus, area, District 



RESULTS OF PROJECT: 



• Consolidated profile with "air information 
needed for campus planning and other needs 

• Individual student profile requested on-line 

• Simple applications furnished to schools 

• Progress made toward moving data to 
campuses 



